Is ftp command DIR supposed to do filename globbing (HiJack 136)? While DIR by itself seems to work OK, DIR followed by a glob pattern (e.g. 1* in fids directory) return a small subset of files actually there, or nothing at all. I think it returns the first consecutive range of files matching the pattern (i.e. that it expects filenames sorted, while theay are not).

BTW, I have noticed that when no connections are active two kftpd and khttpd threads each are there, one 'alive' and one zombie. Zombies disappear when I connect. I suppose that is OK...

Hmmph! Looks like a bug in kftpd. I don't see the bug in the code, though, but it definitely misbehaves with the globbing.

Darn.. Have a look, will you, at the "glob_match()" routine in kftpd.c in the hijack patch.. maybe pull out that one routine (standalone) and build a small test program around it. I just don't see the bug right now, and some other clever eyeballs are needed here.

Thanks.
-ml

Yeah, don't worry about the Zombies.. there should only ever be one (of each kind) around, and that behaviour is "normal" -- the alternative would be to have a special thread just to "wait" for the children dying off.. too much fuss.

A "zombie" is a child thread/process which has died, and whose parent process has not yet done a "wait()" syscall for it.. so the corpse just stays in limbo, not responding to anything (very zombie-like) until the irresponsible parent stops partying and shows up at the cemetary to pay final respects (by invoking "wait()").

With kftpd/khttpd, I only wait() for dead offspring as needed, and also do a quick poll after each new incoming connection.. which explains the behaviour you see.

Cheers

Ahh.. never mind. I found it.

Globbing is fine.. the problem is that a buffer is getting used for two purposes simultaneously.. oops.

I'll put out a v138 shortly with the fix.

Thanks!

Err.. make that v138 (already have a v137 release..)

Your bugs are really moving targets. You fixed this one three releases ago! There goes my shot at fame...

That's what I thought. Excellent description of zombies, BTW! :-)

Er, still (or again) does not work in v140, getting just a screenfull or so of files.

Ahh.. don't ya just love nested bugs..

Okay, the filldir() routine sometimes has no glob matches over a long stretch, which causes it to return nothing, which cases the readdir() loop to think it has finished.

Fixed in v141.

Thanks again.

Yes, that's exactly how it bahaved.

I tried with few examples on v141 (BTW, kernel install via /proc/empeg_kernel works like charm), and it seems to be OK. now.

Thanks!